1. Field of the Invention
The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field. Still more particularly, the present invention relates to preconditioning a storage controller for automated data collection.
2. Description of the Related Art
Storage controllers, such as those available from the International Business Machines Corporation, are known. In storage controllers, it is known for an enterprise storage server to manage Input/Output (I/O) requests from networked hosts to one or more storage units, such as a direct access storage device (DASD), Redundant Array of Independent Disks (RAID Array), and Just a Bunch of Disks (JBOD). Storage controllers include host bus adapters or interfaces to communicate with hosts over a network and adapters or interfaces to communicate with the storage units.
Data integrity is an important factor in large computer data systems. Thus, backup systems have been developed and integrated into storage controllers to prevent the loss of data in the event of various types of failures. If an error occurs on a storage controller, it is desirable to provide a first time data capture or collection (FTDC) type function (also referred to as first failure data capture (FFDC) type function) which can support analysis of the error and eventually enable obtaining a root cause and/or resolution of that error. With a FTDC type system, much of the data collection, such as error report (errpt) data, trace logs, etc., is automatically gathered but is not automatically offloaded. This automatically collected data is often collected in a round robin basis so that new data overlays older data in the collection. This overlay function means that if these logs are not offloaded until well after an error event, the pertinent data can be lost.
Another important aspect of a data collection system is known as a statesave operation, in which control and data structures are accumulated and off-loaded when a statesave is triggered. Many error events can automatically trigger these statesaves (e.g., panics, data storage interrupts (DSIs)), but there are some error events in which automatic triggers are not set because the condition is not necessarily considered an error. Some examples of these pseudo-error conditions include selective resets, system resets, Peer-to-Peer Remote Copy suspends of paths or pairs. Additionally, some of these conditions are not considered errors until some form of threshold is crossed. A notable example of this type of issue is a performance problem where, as long as response time or throughput (e.g., in MB/sec) stays below or above, respectively, some defined threshold, no problem is identified. However, when the thresholds are exceeded, the user/host is impacted. In all these examples, a statesave can be manually forced or forced by triggers set in host software. However, such a manual statesave operation is often well after the event and as such, data critical to the analysis is no longer in the collected data.
Accordingly, it is desirable to allow a user or host to define automated FTDC for both automatically collected data and for pseudo error type conditions based on the environments and needs of a customer.